Assertion failure: mDocument (Illicit document shutdown), at src/accessible/base/NotificationController.cpp:768 ==58708==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f8eb94de661 bp 0x7ffffdb4ceb0 sp 0x7ffffdb4c8e0 T0) ==58708==The signal is caused by a WRITE memory access. ==58708==Hint: address points to the zero page. #0 0x7f8eb94de660 in mozilla::a11y::NotificationController::WillRefresh(mozilla::TimeStamp) src/accessible/base/NotificationController.cpp:705:75 #1 0x7f8eb736b35f in nsRefreshDriver::Tick(long, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:1790:12 #2 0x7f8eb737414e in mozilla::RefreshDriverTimer::TickRefreshDrivers(long, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) src/layout/base/nsRefreshDriver.cpp:300:7 #3 0x7f8eb7373f1d in mozilla::RefreshDriverTimer::Tick(long, mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:321:5 #4 0x7f8eb7377d65 in mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:753:5 #5 0x7f8eb7376886 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) src/layout/base/nsRefreshDriver.cpp:666:35 #6 0x7f8eb7372537 in mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::ParentProcessVsyncNotifier::Run() src/layout/base/nsRefreshDriver.cpp:512:20 #7 0x7f8eb1db4ff1 in nsThread::ProcessNextEvent(bool, bool*) src/xpcom/threads/nsThread.cpp:1302:14 #8 0x7f8eb1dbf1a0 in NS_ProcessNextEvent(nsIThread*, bool) src/xpcom/threads/nsThreadUtils.cpp:393:10 #9 0x7f8eb28e9235 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) src/ipc/glue/MessagePump.cpp:96:21 #10 0x7f8eb28361d7 in MessageLoop::RunInternal() src/ipc/chromium/src/base/message_loop.cc:238:10 #11 0x7f8eb2836069 in MessageLoop::Run() src/ipc/chromium/src/base/message_loop.cc:211:3 #12 0x7f8eb6e9a07a in nsBaseAppShell::Run() src/widget/nsBaseAppShell.cpp:156:27 #13 0x7f8eb9a7a471 in nsAppStartup::Run() src/toolkit/components/startup/nsAppStartup.cpp:283:30 #14 0x7f8eb9bd3a52 in XREMain::XRE_mainRun() src/toolkit/xre/nsAppRunner.cpp:4568:22 #15 0x7f8eb9bd568b in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4748:8 #16 0x7f8eb9bd6578 in XRE_main(int, char**, mozilla::BootstrapConfig const&) src/toolkit/xre/nsAppRunner.cpp:4843:21 #17 0x4eca88 in do_main(int, char**, char**) src/browser/app/nsBrowserApp.cpp:236:22 #18 0x4ec3a0 in main src/browser/app/nsBrowserApp.cpp:309:16 #19 0x7f8ece87482f in __libc_start_main /build/glibc-9tT8Do/glibc-2.23/csu/../csu/libc-start.c:291 #20 0x41e0d4 in _start (m-c-1495643560-asan-debug/firefox+0x41e0d4)

This is apparently caused by bug 1330484 comment 42. We are not going to back that out so we'll need to look at this separately. I am unable to reproduce the issue.

> I am unable to reproduce the issue. To reproduce using this test case the fuzzPriv extension[1] is required. I can repro on ASan and non-ASan debug builds. [1] https://github.com/MozillaSecurity/domfuzz/tree/master/dom/extension Trevor has a setup that should reproduce this.

Tyson, how are you using the extension? To be clear, I'm installing the addon from the link you pasted (run 'make' then drag the .xpi file to the browser) and I get a doorhanger telling me that the addon is incompatible with Firefox 55 -- and this clearer message in the debug console: 1496253953151 addons.xpi WARN disabling domfuzz@squarefree.com since it is not multiprocess compatible ...which is bad since this is an e10s bug. Did you do an extra step to get it to work? Are you sure the fuzzpriv extension is running?

Adding that this has only been seen so far in Linux builds (ASAN and not). I currently believe that this is not an issue on Windows. Also, this is seen by using the fuzzer (above), it is at least uncommon in normal activity. The bug was found using the ffpuppet automation tool but its probably not required to see the failure.

After speaking with tsmith about this, I am finally able to reproduce the issue. Here's what I was missing: STR: 1. Make a Linux debug build (64-bit) 2. Download the ffpuppet automation tool [1], which I actually _did_ need to reproduce this since the fuzzer addon is incompatible with e10s but "somehow" the ffpuppet tool gets around this. 3. Install ffpuppet. The install instructions are off -- on a fresh install of Linux Mint) I did: > pip install --upgrade -r requirements.txt --user 4. Fetch the domfuzz extension as explained in comment 2. 5. Download the prefs-default.js and test_case.html attachments. 6. Run: > python ffpuppet.py <path_to_executable>/firefox -p prefs_default.js -e extension/ -u test_case.html -d I don't know what the expected behavior is but since it crashes almost immediately after opening a browser window, I'll say it does the wrong thing. [1] https://github.com/MozillaSecurity/ffpuppet

(In reply to David Parks (dparks) [:handyman] from comment #5) > After speaking with tsmith about this, I am finally able to reproduce the > issue. Here's what I was missing: > > STR: > > 1. Make a Linux debug build (64-bit) > 2. Download the ffpuppet automation tool [1], which I actually _did_ need to > reproduce this since the fuzzer addon is incompatible with e10s but > "somehow" the ffpuppet tool gets around this. > 3. Install ffpuppet. The install instructions are off -- on a fresh install > of Linux Mint) I did: > > pip install --upgrade -r requirements.txt --user > 4. Fetch the domfuzz extension as explained in comment 2. > 5. Download the prefs-default.js and test_case.html attachments. Where is prefs-default.js? Don't see the attachement here. More importantly, is this with or without e10s?

(In reply to Eitan Isaacson [:eeejay] from comment #6) > Where is prefs-default.js? Don't see the attachement here. More importantly, > is this with or without e10s? fuzzing-no-e10s.prefs.js is a copy of the same file and you can get it here: https://github.com/MozillaSecurity/ffpuppet/tree/master/prefs/ And as the name suggests e10s is disabled.

I just tested with m-c Changeset: 16ffc1d05422a81099ce8b9b59de66dde4c8b2f0 Build ID: 20170728132457 This issue is no longer reproducible. It likely got fixed by one of the many other fixes that have gone in lately.

worksforme per comment 8